home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20021006-20030409 / 000177_fdc@columbia.edu_Wed Dec 11 15:11:14 EST 2002.msg < prev    next >
Text File  |  2003-04-08  |  3KB  |  79 lines
  1. Article: 13958 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: remote dir
  6. Date: 11 Dec 2002 15:10:49 -0500
  7. Organization: Columbia University
  8. Lines: 62
  9. Message-ID: <at8649$2qj$1@watsol.cc.columbia.edu>
  10. References: <suMJ9.34$CC2.77960@news.uswest.net>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1039637450 7420 128.59.39.139 (11 Dec 2002 20:10:50 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 11 Dec 2002 20:10:50 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13958
  16.  
  17. In article <suMJ9.34$CC2.77960@news.uswest.net>,
  18. Frank Huang <huang@monair.com> wrote:
  19. : Hi Everyone:
  20. :     I am using TurboPower Async ActiveX.
  21. :     On the client, I sent a 'G' packet with 'D' as the Data field.
  22. :     Then on 3.15 Server, it tries to send $KERMIT$.TMP over, but when I
  23. : tries to receive the file, it logs
  24. :     the following messages.
  25. :     On the server and client, I have the Block-check-type set to be CRC
  26. :     If I sent a 'G' packet with 'FINISH' or 'LOGOUT' as the Data field, then
  27. :     it works find.
  28. :
  29. We don't provide a debugging service for competitors who sell unlicensed
  30. implementations of our protocol.  MS-DOS Kermit 3.15 includes a correct
  31. implementation that can be used on DOS and on Windows 3.x.  MS-DOS Kermit 
  32. is not supported on 32-bit Windows, which has its own Kermit software,
  33. Kermit 95:
  34.  
  35.   http://www.columbia.edu/kermit/k95.html
  36.  
  37. But that's not the problem in this case.
  38.  
  39. Your log shows:
  40.  
  41. : Rpack: ^A, GD READ.ME6^M
  42. : Spack: ^A5 S~( @-#Y3~^?5% ___E#^M
  43. : Rpack: ^A0 Yp% @-#Y3~ !  Z^M
  44. : Spack: ^A)!Xdir !R>^M
  45. : Rpack: ^A# N&0
  46. : <Bad checksum>
  47. :
  48. MS-DOS Kermit sent a correct X packet with the three-byte block check (CRC)
  49. that was successfully negotiated.  The other Kermit could not read it and 
  50. sent a NAK.  Furthermore the NAK itself is malformed (it claims to have a
  51. 1-byte checksum, but in fact has a two byte one; even if you ignore the
  52. spurious second byte, the first one is wrong):
  53.  
  54. : Spack: ^A'!Xdir "^M
  55. : Rpack: 6^M^A# N&0
  56. : <Bad checksum>
  57. :
  58. Since it keeps happening, it's not because of transmission errors; it's
  59. because the other Kermit program is totally broken.  Maybe it will work
  60. better with 1-byte checksums.
  61.  
  62. If you want to embed Kermit protocol in a Windows application you are
  63. developing, perhaps you should come to us for it since we know the protocol
  64. and actually go to some lengths to implement it correctly and efficiently.
  65. See:
  66.  
  67.   http://www.columbia.edu/kermit/k95faq.html#embedding
  68.  
  69. and:
  70.  
  71.   http://www.columbia.edu/kermit/ek.html
  72.  
  73. Better still, companies that make products like the one you are trying to
  74. use should come to us and license a supported implementation, instead of
  75. torturing their customers as well as end-users (not to mention us and the
  76. readers of this newsgroup) with broken and/or substandard implementations.
  77.  
  78. - Frank
  79.